金融信创 | 浅析银行核心业务国产改造方案

近日，由腾讯云主办的“国产数据库金融行业应用与技术论坛”线上举行，神州信息金融技术部总经理张劲分享神州信息在银行核心业务国产改造方案方面的创新实践。

随着过去两年对银行金融信创的探索，我们开始了对银行的核心业务系统即通常意义的存贷或业务系统，进行国产化改造升级。今天分享的内容主要是：第一，当前整体金融行业在核心替代方面的要求和我们的理解；第二，结合神州信息过去二十年的核心业务系统经验和近三年深度参与的金融信创尤其是金融核心改造，分享一些想法和典型案例。

▌政策要求及解读

从政策要求角度看，核心业务系统改造和原有的一般业务系统（关键业务系统、OA业务系统）改造有着非常大的差别。今年我们信创的一批、二批乃至三批用户在进行核心业务系统的信创改造过程中，包括大行、城商行、保险、基金、证券在内客户的核心业务系统改造遇到的难度超出过往。

▌整体核心业务系统的难点

第一个层面是基础软硬件方面，核心业务系统对无论国产服务器、国产操作系统、国产中间件和国产数据库，在整体稳定性、高性能方面有了更高要求。尤其是大量银行原有的核心业务系统构建在国外小型机、操作系统、存储乃至数据库的环境下，客户对核心业务系统配置到全国产化环境缺乏信心。

第二个层面是监管要求方面，对信创的核心系统改造提出了不同路径，包括生产环境、灾备环境和测试环境。今年我们看到，绝大部分用户开始针对核心业务系统替代方案进行规划设计，乃至在年底时上报整体可实现路径，在2023年初步实现上述三路径中的一个环境。同时在核心业务系统改造过程中，需要针对开源、第三方组件做相关管理。因为核心业务系统的业务等级和对于业务粘性的要求非常高，需要根据一些核心业务过程使用开源的情况做有效管理，甚至要及时修复使用中的漏洞。

▌三个需要特别关注的重点

在核心业务系统的替代过程中，无论单轨还是双轨模式的改造，都存在非常多的难点和重点。

第一点，在核心业务系统的构建过程中，一定存在信创云平台，对它需要做整体信创资源的聚合复用，包括后续相关组件的迁移管理以及整个资源环境的运维运营管理。

第二点，未来的核心业务系统一定构建在分布式技术平台上，把分布式技术平台引入信创核心改造过程十分重要，包括多活数据中心需要、大量服务组件如何实现服务化，以及对核心业务系统中大量分布式事务的管理。

第三点，绝大部分金融行业的核心业务系统数据库都需要根据类型、核心改造模式、规模和需求，合理选择集中式和分布式，但很多金融业务都选择采用分布式、微服务的方式实现数据库的改造替换。数据库是影响核心性能的重要资源，购买大量物理服务器，运行大量SSD和一些高端计算、存储资源，并不意味着能够保障核心性能快速稳定运行。数据库的选择和合理配置、运行维护都是影响核心性能的重要要素。

▌建议改造方案

最近的三四个月中我参与了多家银行针对核心业务系统改造的方案，在此简要介绍。

目前的主流环境有三种场景：并行环境、测试环境、灾备环境，各有一定的优缺点。

并行环境与现有生产环境组成AB角，区分业务场景或采用双写方式共同组成核心系统。优势是对于现有生产的异样影响较少，劣势是投资、维护成本相对较高。

测试环境是通过搭建信创的核心测试开发环境，新上的业务系统经过验证后再上线，最近很多客户为快速推进核心信创进行了选择。优势是投资较小、不影响现有政策，劣势是没有承载真正的生产，对未来监管的进一步要求存在一些不确定性。

灾备环境是在不改变现有生产环境的前提下，构建信创灾备的核心系统，能够实现对主中心的容灾。优势和并行环境一样，不影响现有生产；劣势是数据同步的RTO、RPO需要做仔细考量，对很多技术实现尤其是数据库的同步，可能存在一些技术上的难点或风险。

不管选择哪种环境，相关的架构设计以及数据库选型，都是关注重点。从信创改造的最佳实践也可以看到，结合过去一般业务系统、关键业务系统选型，神州信息在终端、服务器、操作系统，服务数据库、分布式平台、云平台方面积累了很多经验。包括服务器端的主流相关厂商，国内目前以鲲鹏、海光为主；操作系统方面，服务器端麒麟更多，终端方面可能是统信；数据库方面，尤其是分布数据库百花齐放，包括 TDSQL、OceanBase、GaussDB等，它们各有优缺点，最终还是要结合实际情况，通过PoC结合改造验证以及后续运维的掌握来评估。当然也有一些传统集中式数据库存在，但核心业务系统替代一定引入了分布式的技术平台，因其能够实现应用和数据库的结合，更好地构建一个面向未来的分布式和微服务的核心业务系统。

总体而言，核心业务系统的现状改造，涉及到整个操作系统、服务器、数据库、中间件、分布式平台、云平台的一系列完整过程，核心业务系统的替代时间可能长达3年甚至5年。

▌核心业务系统替代的五个层面

第一层，统一硬件平台，包括基础架构中的信创服务器、x86服务器、分布式存储、集中式存储、信创网络和信创的安全设备，构成基础架构环境。

第二层，统一基础平台，包括裸金属、虚拟机、块存储、文件存储、网络资源、安全资源、灾备。

第三层，数据库服务，包括分布式数据库、异构数据同步CDC。

第四层，技术平台，包括业务处理框架、分布式技术平台、开发平台、运维监控。

第五层，业务应用，包括会计核算模型、产品工厂、查询服务、客户信息模型。

通过对五层架构逐步、按计划的改造升级，才能够真正完成核心业务系统的计划工作。

▌核心业务系统信创改造的两个核心

第一个核心是数据库，我们认为数据库的替代是目前的核心业务系统替代过程中最大的难点。如何选择合适的数据库来替代现有主流的国外数据库环境，中行、秦皇岛银行及其他客户都给了我们一些非常珍贵的启示。

另一个核心就是可能要针对整个核心数据库，进行拆表拆库的拆分，将相关的功能下移到国产数据库环境，完成信创改造的目标。

从过往经验来看，银行客户在做核心数据库的架构时有两种不同的选择路线。大行客户更多采用单元化的方式进行核心数据库构建，中小行的客户更多采用分布式和微服务的方式进行核心数据库构建。

两种路线各有优劣，单元化方式的优点非常明显，包括高效扩容、灰度发布、数据库的应用无切入，缺点是对资源的利用率较低、对运维的自动化要求较高、应用层要做跨单元事务的分布分表，这对客户自身的科技条件，尤其是软件开发条件的要求会更高一点。

采用分布式加微服务的方式进行核心数据库改造的路线，优点是服务级的扩容比较方便，数据库已经实现了分布式的事务应用相对简单；缺点是在极端环境下故障的影响面可能会大一些，应用需要做相关的改造。

我们的核心业务系统会大量利用国外数据库的存储过程来实现核心数据库的加速，但在分布式环境中，可能通过一些对核心业务系统的改造来完成对于国产分布式数据库的适配。过去两年里中和腾讯TDSQL做了大量的适配，来满足业务系统对于数据库相关的一些要求。

在数据库的核心拆库方面，我们也做出了一些最佳实践。由于整个业务系统的模块非常之多，在数据库拆分的时候，我们建议优先拆分参数工厂、数据管理、会计核算、产品工厂、贷中管理等业务模块，真正的账务拆分顺序可以稍微滞后，这也是为了更有效地验证和使用国产化的环境，满足核心业务系统的相关要求。

针对数据库，我们认为在核心系统的数据信创改造过程中，安全管控非常重要，包括事前管理、事中管理、事后管理，其中包括数据库的权限管理、开发安全规范、安全审计。一方面可以结合腾讯的赤兔、扁鹊做相关管理，另一方面，从金融机构角度要建立非常完善的流程和制度，比如数据库的变更、审批的授权、多种用户的限制策略、事中的危险操作的阻断、实时报警、事后的非应用端的操作审计和问题追溯等等。

理想的核心改造最终目标，是在原有的分布式核心中，通过核心的信创改造，可以在信创服务器、分布式存储基础、信创网络上，基于信创云的环境、IaaS、TDSQL，通过我们的分布式技术平台来完成客户的存贷汇业务、相关的总账、支付业务。最终实现真正监管以及国家对于金融行业风险最高、难度最大的改造任务的达成。

——如果你觉得不错，点个在看吧。

END

点击图片查看完整内容：